home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1685.txt < prev    next >
Text File  |  1997-04-01  |  21KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      H. Alvestrand
  8. Request for Comments: 1685                                       UNINETT
  9. RARE Technical Report: 12                                    August 1994
  10. Category: Informational
  11.  
  12.  
  13.                         Writing X.400 O/R Names
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet Community.  It does
  18.    not specify an Internet Standard of any kind.  Distribution of this
  19.    memo is unlimited.
  20.  
  21. 1. Introduction
  22.  
  23.    There is a need for human beings who use X.400 systems to be able to
  24.    write down O/R names in a uniform way.
  25.  
  26.    There has been a preexisting recommendation on how to write O/R names
  27.    for human consumption in the RARE community. Now that the ISO/ITU has
  28.    adopted a recommendation on how to do this [1], RARE needs to update
  29.    its recommendation on writing O/R names to take this standard into
  30.    account.
  31.  
  32. 2. Recommendations on writing O/R names
  33.  
  34.    RARE recommends that the ISO standard be followed when writing O/R
  35.    names. The ISO/ITU standard contains a number of options. RARE makes
  36.    the following recommendations:
  37.  
  38.       -    The "main" abbreviations, G, I, S, O, OU1, OU2, P, A and C
  39.            are used. They should be written using UPPER CASE.
  40.  
  41.       -    The separation character should be semicolon (;).
  42.  
  43.       -    The ADMD value "blank" is expressed by omitting the
  44.            attribute. No other interpretation of a missing ADMD
  45.            attribute is allowed.
  46.  
  47.       -    The recommended sequence is G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;
  48.  
  49.    This means that the O, OU1 and so on will be in opposite order to the
  50.    fields of an Internet domain name; the reason for choosing the
  51.    ISO/ITU order is that this will be more common among users of X.400
  52.    services.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 1]
  59.  
  60. RFC 1685                Writing X.400 O/R Names              August 1994
  61.  
  62.  
  63. 3. Copy of the recommmendation
  64.  
  65.    This is a COPY of a DRAFT of the relevant appendix. For the
  66.    authoritative text, consult the ITU standard itself.
  67.  
  68.    Final text for AMENDMENT, 7 February 1993
  69.  
  70.    Annex to CCITT Rec. F.401 and ISO/IEC 10021-2/Am.1
  71.  
  72.    Annex F
  73.  
  74.       Representation of O/R addresses for human usage (This annex does
  75.       not form an integral part of this Recommendation|International
  76.       Standard)
  77.  
  78.    F.1 Purpose
  79.  
  80.       An O/R address (specified in clause 18) consists of a set of
  81.       values of attributes taken from the list shown in Table F.1. In
  82.       order to represent visually an address to a human user, and to
  83.       enable the user to enter the address into a user interface, each
  84.       attribute value needs to be associated with the correct attribute
  85.       type. Many of the names of the attribute types shown in Table F.1
  86.       are too long for convenient usage on paper or a screen. There is a
  87.       need for a format which allows attributes to be represented
  88.       concisely, e.g., on a business card.
  89.  
  90.       This annex specifies how addresses can be expressed concisely
  91.       using labels to represent the attribute types. There are three
  92.       categories of attributes: those standard mnemonic attributes which
  93.       are most likely to be found in O/R addresses represented for human
  94.       usage (e.g., on business cards), those used in physical delivery
  95.       addresses, and other specialised attributes (including domain
  96.       defined attributes). In order to provide a format which is as
  97.       concise as possible, many of the labels are single characters.
  98.       This also makes them less language dependent.
  99.  
  100.       Clause F.3 specifies the format for the representation of
  101.       addresses, and clause F.4 specifies the characteristics necessary
  102.       for user interfaces which are intended to be used in conjunction
  103.       with this format.
  104.  
  105.    F.2 Scope
  106.  
  107.       A labelled format for the communication of O/R addresses to human
  108.       users is specified. The format consists of a set of pairs of
  109.       labels and attribute-values. The characteristics of a user
  110.       interface which are necessary to accept addresses given in this
  111.  
  112.  
  113.  
  114. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 2]
  115.  
  116. RFC 1685                Writing X.400 O/R Names              August 1994
  117.  
  118.  
  119.       format are also specified.
  120.  
  121.       In addition a self-explanatory format suitable for use where there
  122.       is more space, e.g., in printed material and in the user
  123.       interface, is specified.
  124.  
  125.    F.3 Format
  126.  
  127.    F.3.1 General
  128.  
  129.       The objective of the labelled format is to enable O/R addresses to
  130.       be represented in a format which is concise and which can be
  131.       accurately transcribed by human users. This can be facilitated by
  132.       careful consideration of which attributes and values are used to
  133.       form an O/R address.
  134.  
  135.       If the attributes of an O/R address include characters from an
  136.       extended character set, human users who do not normally use the
  137.       same extended character set may have difficulty representing the
  138.       O/R address or entering it into their messaging system. In this
  139.       situation, an alias of the O/R address should be provided which is
  140.       composed entirely of printable string characters.
  141.  
  142.    NOTES
  143.  
  144.       1.   The policy for structuring O/R addresses needs to be
  145.            carefully considered. Individual O/R addresses should be
  146.            allocated within an appropriate division of the address
  147.            space to reduce to an acceptable level the probability that
  148.            2 users might expect to have the same O/R address. Use of
  149.            given name or initials is usually sufficient to distinguish
  150.            between users. It may be inappropriate to reflect too much
  151.            granularity in OUs particularly if the organizational
  152.            structure is subject to frequent change, or users move
  153.            between OUs.
  154.  
  155.       2.   There may be a conflict between the benefits of using long
  156.            values for attributes which are self explanatory (such as
  157.            the full name of an organisation) and the benefits of
  158.            shorter values (e.g., to concisely fit on a business card).
  159.            One solution to this problem is to provide an alternative
  160.            short attribute value (such as the initials of the
  161.            organisation) as an alias for the long value.
  162.  
  163.       3.   If a human user might be uncertain about the existence of a
  164.            space in an attribute value (particularly when it is
  165.            typeset), aliases could be provided with and without the
  166.            space (e.g., "SNOMAIL400" as an alias for "SNOMAIL 400" and
  167.  
  168.  
  169.  
  170. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 3]
  171.  
  172. RFC 1685                Writing X.400 O/R Names              August 1994
  173.  
  174.  
  175.            "Mac Donald" as an alias for MacDonald).
  176.  
  177.       4.   If an alias is provided for an O/R address, it is desirable
  178.            that this is implemented in such a way that a consistent
  179.            (preferred) form of O/R address is generated for all
  180.            messages originated by the user.
  181.  
  182.       Where national usage permits a single space value for the ADMD in
  183.       an address, this is represented in the address either by omitting
  184.       the ADMD attribute, or showing the ADMD attribute with no value or
  185.       the value of a space.
  186.  
  187.    F.3.2 Labelled format
  188.  
  189.    F.3.2.1 Syntax
  190.  
  191.       O/R addresses in labelled format consist of delimited pairs of
  192.       labels and values in the syntax <label>"="<value>. The labels for
  193.       each attribute are specified in Tables F.1, F.2 and F.3. (The
  194.       physical delivery attributes in Table F.2 are included for
  195.       completeness.) The label and its value are either separated by the
  196.       character "=", or by the space between two columns in a table.
  197.       Labels may be represented in upper or lower case, but the use of
  198.       uppercase is recommended as it is likely to be more visually
  199.       distinctive.
  200.  
  201.       If label/value pairs appear in sequence on a line, they are
  202.       separated by delimiters. Delimiters may optionally be followed by
  203.       one or more spaces. The delimiter character may be either ";" or
  204.       "/", but only one of these can be used in one O/R address. When
  205.       the delimiter is "/" the first label is prefixed by "/". The use
  206.       of a delimiter at the end of a line is optional. If the value of
  207.       any attribute contains the delimiter character, this is
  208.       represented by a pair of delimiter characters.
  209.  
  210.       If an identifier is required to preface a labelled address, it is
  211.       recommended that "X.400" is used.
  212.  
  213.       If an address is entirely composed of attributes contained in
  214.       Table F.1, it is recommended that the sequence of attributes in
  215.       the address is that given in Table F.1. If this sequence is
  216.       incompatible with normal cultural conventions, an alternative
  217.       sequence may be adopted for representations of addresses which are
  218.       primarily intended for use within that culture.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 4]
  227.  
  228. RFC 1685                Writing X.400 O/R Names              August 1994
  229.  
  230.  
  231.    EXAMPLE
  232.  
  233.     X.400: G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq
  234.  
  235.     This address may also be layed out as a table:
  236.  
  237.     G     John
  238.     S     Smith
  239.     O     A Bank Ltd
  240.     P     ABL
  241.  
  242.  
  243.     A     Snomail
  244.     C     AQ
  245.  
  246.     Table F.1. Standard Attributes of the Mnemonic Address Form
  247.  
  248.     Attribute Type                         Abbreviation      Label
  249.                                            (where necessary)
  250.  
  251.     Given Name                             Given name        G
  252.     Initial                                Initials          I
  253.     Surname                                Surname           S
  254.     Generation Qualifier                   Generation        Q
  255.     Common Name                            Common Name       CN
  256.     Organization                           Organization      O
  257.     Organizational Unit 1                  Org.Unit.1        OU1
  258.     Organizational Unit 2                  Org.Unit.2        OU2
  259.     Organizational Unit 3                  Org.Unit.3        OU3
  260.     Organizational Unit 4                  Org.Unit.4        OU4
  261.     Private Management Domain Name         PRMD              P
  262.     Administration Management Domain Name  ADMD              A
  263.     Country                                Country           C
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 5]
  283.  
  284. RFC 1685                Writing X.400 O/R Names              August 1994
  285.  
  286.  
  287.     Table F.2. Physical Delivery Attributes
  288.  
  289.     Physical Delivery Personal Name        PD-person         PD-PN
  290.  
  291.     Extension of Postal O/R Address
  292.     Components                             PD-ext.address    PD-EA
  293.     Extension of Physical Delivery Address
  294.     Components                             PD-ext.delivery   PD-ED
  295.     Physical Delivery Office Number        PD-office number  PD-OFN
  296.     Physical Delivery Office Name          PD-office         PD-OF
  297.     Physical Delivery Organization Name    PD-organization   PD-O
  298.     Street Address                         PD-street         PD-S
  299.     Unformatted Postal Address             PD-address        PD-A1
  300.                                                              PD-A2
  301.     (there are individual labels for                         PD-A3
  302.     each line of the address)                                PD-A4
  303.                                                              PD-A5
  304.                                                              PD-A6
  305.     Unique Postal Name                     PD-unique         PD-U
  306.     Local Postal Attributes                PD-local          PD-L
  307.     Postal Restante Address                PD-restante       PD-R
  308.     Post Office Box Address                PD-box            PD-B
  309.     Postal Code                            PD-code           PD-PC
  310.     Physical Delivery Service Name         PD-service        PD-SN
  311.     Physical Delivery Country Name         PD-country        PD-C
  312.  
  313.     Table F.3. Other Attributes
  314.  
  315.     X.121 Network Address                  X.121             X.121
  316.     E.163/E.164 Network Address            ISDN              ISDN
  317.     PSAP Network Address                   PSAP              PSAP
  318.     User Agent Numeric ID                  N-ID              N-ID
  319.     Terminal Identifier                    T-ID              T-ID
  320.     Terminal Type                          T-TY              T-TY
  321.     Domain Defined Attribute               DDA:<type>
  322.     DDA:<type>
  323.  
  324.     where the notation <type> identifies the type of domain defined
  325.     attribute.
  326.  
  327.    F.3.2.2 Terminal Type
  328.  
  329.       There are currently six terminal types, and if international
  330.       consistency is required the following specific abbreviations
  331.       should be used to represent the values for these types: tlx, ttx,
  332.       g3fax, g4fax, ia5 and vtx.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 6]
  339.  
  340. RFC 1685                Writing X.400 O/R Names              August 1994
  341.  
  342.  
  343.    F.3.2.3 Domain Defined Attribute
  344.  
  345.       The label for a DDA consists of "DDA:" followed by the DDA type.
  346.       If an address includes more than one DDA of the same type, it is
  347.       assumed that the DDAs are intended to be processed in the sequence
  348.       in which they are represented.
  349.  
  350.       EXAMPLE - DDA:RFC-822=fred(a)widget.co.uk; O=gateway; P=abc; C=gb
  351.  
  352.       If the <type> of a DDA type includes the character "=", it is
  353.       represented by "==".
  354.  
  355.    F.3.3 Self-explanatory format
  356.  
  357.       The self-explanatory format may be used when space is available.
  358.       It consists of a list of the attribute types, either in full or
  359.       abbreviated. The attribute types or abbreviations may be in any
  360.       language, but each attribute type or abbreviation in Table F.1 is
  361.       followed by the specified label. If English language abbreviations
  362.       are used, they should be those given in Tables F.1, F.2 and F.3.
  363.  
  364.       If an address is entirely composed of attributes contained in
  365.       Table F.1, it is recommended that the sequence of attributes in
  366.       the address is that given in Table F.1. If this sequence is
  367.       incompatible with normal cultural conventions, an alternative
  368.       sequence may be adopted for representations of addresses which are
  369.       primarily intended for use within that culture.
  370.  
  371.     EXAMPLE 1 - Using attribute types in the Norwegian language
  372.  
  373.     Fornavn (G)                            Per
  374.     Etternavn (S)                          Hansen
  375.     Organisasjon (O)                       Teledir
  376.     Organisasjonsenhet (OU1)               Forskning
  377.     Privat domene (P)                      Tele
  378.     Administrasjonsdomene (A)              Telemax
  379.     Land (C)                               NO
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 7]
  395.  
  396. RFC 1685                Writing X.400 O/R Names              August 1994
  397.  
  398.  
  399.     EXAMPLE 2 - Using attribute types and abbreviations in the English
  400.                 language
  401.  
  402.     Given name (G)                         John
  403.     Surname (S)                            Smith
  404.     Organization (O)                       A Bank Ltd
  405.     Org. Unit (OU1)                        IT Dept
  406.     Org. Unit (OU2)                        MSG Group
  407.     PRMD (P)                               ABL
  408.     ADMD (A)                               Snomail
  409.     Country (C)                            AQ
  410.  
  411.    F.4 User interface
  412.  
  413.       This clause specifies the characteristics of a user interface
  414.       which are necessary to enable a user to input O/R addresses
  415.       represented in either of the formats specified in clause F.3.
  416.  
  417.       It is necessary for the user interface to be able to accept any
  418.       valid combination of attributes from Tables F.1, F.2 and F.3.
  419.  
  420.       If the user interface lists the attributes given in Table F.1, it
  421.       is recommended that either the sequence used in Table F.1 should
  422.       be used, or if this sequence is incompatible with normal cultural
  423.       conventions, the alternative sequence adopted within a particular
  424.       culture.
  425.  
  426.       If the user supplies a value for the PRMD attribute but omits the
  427.       ADMD attribute, or omits the value for the ADMD attribute, the
  428.       ADMD value to be used is a single space.
  429.  
  430.       Where an interface accepts an O/R address as a single string
  431.       (e.g., in a command line interface), it is necessary to accept any
  432.       valid labelled format address allowing the user to enter either
  433.       delimiter. The interface should not require the attributes to be
  434.       specified in any particular order. The interface should accept
  435.       labels in upper or lower case.
  436.  
  437.       NOTE - For some existing command line interfaces it may be
  438.       necessary to enclose the whole labelled format address in quotes.
  439.  
  440.       If any other type of interface is provided (e.g., a prompting or
  441.       form-fill interface), it is necessary to provide a means which
  442.       enables the user to easily associate the identity of each
  443.       attribute with the labels specified in Tables F.1, F.2 and F.3.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 8]
  451.  
  452. RFC 1685                Writing X.400 O/R Names              August 1994
  453.  
  454.  
  455.    NOTES
  456.  
  457.       1.   One way to associate the identity of each attribute with the
  458.            labels is to follow the attribute type (or abbreviation) for
  459.            each attribute with the label in brackets, for example:
  460.  
  461.            Given name (G)
  462.            Initials (I)
  463.            Surname (S)
  464.            Generation Qualifier (Q)
  465.            Common Name (CN)
  466.            Organization (O)
  467.            Organizational Unit 1 (OU1)
  468.            Organizational Unit 2 (OU2)
  469.            Organizational Unit 3 (OU3)
  470.            Organizational Unit 4 (OU4)
  471.            Private Management Domain Name (P)
  472.            Administration Management Domain Name (A)
  473.            Country (C)
  474.  
  475.       2.   Many users may have difficulty copying an address presented
  476.            as a table (either in labelled or self-explanatory format)
  477.            into a command line interface which uses delimiters.
  478.  
  479.       3.   For form-fill style interfaces, user performance will be
  480.            optimised when the interface most closely resembles the
  481.            format of the supplied address with the same sequence of
  482.            attributes using the same attribute types or labels.
  483.  
  484.     Examples of application
  485.  
  486.       1.   The Norwegian user of a command line interface receives a
  487.            business card containing the following O/R address:
  488.  
  489.            G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq
  490.  
  491.            The command line interface enables the user to type in the
  492.            address exactly as presented on the card.
  493.  
  494.       2.   The Norwegian user of a form fill interface receives the
  495.            same business card. The form on the screen includes the
  496.            following field names:
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. RARE Working Group on Mail and Messaging (WG-MSG)               [Page 9]
  507.  
  508. RFC 1685                Writing X.400 O/R Names              August 1994
  509.  
  510.  
  511.            Fornavn (G)
  512.            Etternavn (S)
  513.            Organisasjon (O)
  514.            Privat domene (P)
  515.            Administrasjonsdomene (A)
  516.            Land (C)
  517.  
  518.            The user is able to fill in the form by associating the
  519.            single letter labels on the business card with the same
  520.            labels in brackets after the Norwegian names of the
  521.            attributes on the screen. (For form fill input the
  522.            delimiters are not used.)
  523.  
  524.       3.   The English speaking user of a command line interface
  525.            receives a document quoting the following O/R address:
  526.  
  527.            Fornavn (G)               Per
  528.            Etternavn (S)             Hansen
  529.            Organisasjon (O)          Teledir
  530.            Organisasjonsenhet (OU1)  Forskning
  531.            Privat domene (P)         Tele
  532.            Administrasjonsdomene (A) Telemax
  533.            Land (C)                  NO
  534.  
  535.            The user knows how to transform the address from self-
  536.            explanatory to labelled format. The user can choose to enter
  537.            the address with either delimiter, e.g.,:
  538.  
  539.           g=per;s=hansen;o=teledir;ou1=forskning;p=tele;a=telemax;c=no
  540.  
  541.            or:
  542.  
  543.          /g=per/s=hansen/o=teledir/ou1=forskning/p=tele/a=telemax/c=no
  544.  
  545. 4. References
  546.  
  547.  
  548.    [1]  F.401 - CCITT Message Handling Services - Operations
  549.         and Definitions of Service - Naming and Addressing
  550.         for Public Message Handling Services, Annex B
  551.         (08/92).
  552.  
  553.         Available (at the time of writing) as the GOPHER URL:
  554.  
  555.         gopher://info.itu.ch/9/.1/ITUdoc/.dirtree/.1/.itu-
  556.         t/.rec/.f/.23068/.7724.zip
  557.  
  558.  
  559.  
  560.  
  561.  
  562. RARE Working Group on Mail and Messaging (WG-MSG)              [Page 10]
  563.  
  564. RFC 1685                Writing X.400 O/R Names              August 1994
  565.  
  566.  
  567. 5. Security Considerations
  568.  
  569.    Security issues are not discussed in this memo.
  570.  
  571. 6. Author's Address
  572.  
  573.    Harald Tveit Alvestrand
  574.    UNINETT A/S
  575.    P.O.Box 6883
  576.    ELGESETER
  577.    N-7002 TRONDHEIM
  578.    NORWAY
  579.  
  580.    RFC822: Harald.Alvestrand@uninett.no
  581.    X.400:  C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand;
  582.    G=harald
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. RARE Working Group on Mail and Messaging (WG-MSG)              [Page 11]
  619.  
  620.